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ABSTRACT 

Recent years have brought about a paradigm shift within NASA and the Space Launch 
Community regarding the performance of conceptual design. Reliability, maintainability, 
supportability, and operability are no longer effects of design; they have moved to the forefront 
and are affecting design. A primary focus of this shift has been a planned decrease in vehicle 
turnaround time. Potentials for instituting this decrease include attacking the issues of removing, 
refurbishing, and replacing the engines after each flight. 

With new reusable engine designs required to have a turnaround time of two weeks or 
less, it is important to understand the operational affects of an engine on turnaround time, ground 
support personnel and equipment. One tool for visualizing this relationship involves the creation 
of a Discrete Event Simulation (DES). A DES model can be used to run a series of trade studies 
to determine if the engine is meeting its requirements, and, if not, what can be altered to bring it 
into compliance. Using DES, it is possible to look at the ways in which labor requirements, 
parallel maintenance versus serial maintenance, and maintenance scheduling affect the overall 
turnaround time. 

A detailed DES model of the Space Shuttle Main Engines (SSME) has been developed. 
Trades may be performed using the SSME Processing Model to see where maintenance 
bottlenecks occur, what the benefits (if any) are of increasing the numbers of personnel, or the 
number and location of facilities, in addition to trades previously mentioned, all with the goal of 
optimizing the operational turnaround time and minimizing operational cost. The SSME 
Processing Model was developed in such a way that it can easily be used as a foundation for 
developing DES models of other operational or developmental reusable engines. Performing a 
DES on a developmental engine during the conceptual phase makes it easier to affect the design 
and make changes to bring about a decrease in turnaround time and costs. 

INTRODUCTION 

In 1998, Rick Christenson and D.R. Komar of NASA-MSFC published a report entitled 
Reusable Rocket Engine Ooerabilitv Modeling and Analysis 1 11 . In their report they stated that an 
effective operations model supported by data from an existing system would help in designing a 
new propulsion system for minimal ground support. For their report, Mr. Christenson and Mr. 
Komar collected maintenance data on the SSME from the Shuttle Program. The data collected 
contained over 1000 planned maintenance tasks, including the mean duration, predecessors, and 
labor requirements for each task, in addition to data on unplanned maintenance. With the help of 
NASA-MSFC’s Barney Holt, Mr. Christenson and Mr. Komar developed a DES of the SSME 
maintenance process based upon the data they had collected. 

Their original SSME Processing Model was developed using an off the shelf program 
called Extend, developed by Imagine That! 121 . Extend is a discrete event simulation tool that 
allows designers to develop dynamic models of real-life processes in a wide variety of fields by 
creating models from building blocks, exploring the process involved, determining relationships, 
and then changing assumptions to arrive at an optimum solution. The original SSME Processing 
Model captured the SSME maintenance that is performed on the runway, Orbiter Processing 


conflicts to occur. Of the 1000 plus maintenance tasks that had been identified, only 60 high level 
tasks were included in the original model along with a number of unplanned maintenance tasks 
which had been identified. 

In 2002 a new effort began to increase the capabilities of the original SSME Processing 
Model and develop a method in which the SSME Processing Model could be used as the 
foundation for other engine models. In addition to enhancing the model itself an additional 
objective was to update the data used by the model. The original data was from the 1 998 time 
frame when engine maintenance was still performed in the VAB. By 2002 the SSME Processing 
Facility had been built and the SSME maintenance had moved out of the VAB. Also, between 
1998 and 2002 several upgrades to the engines were made which have had an effect on the 
maintenance tasks. The original SSME Processing Model was used as the starting point for 
developing the new SSME Processing Model. 

The SSME Processing Model focuses on the same key areas of operations for the SSME 
as the original model and includes the SSME processing facility, where six SSMEs can be 
worked on simultaneously as well as depot maintenance, and engine retirement. Figure 1 shows 
the opening screen of the SSME Processing Model and the seven areas of operations. 
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Figure 1 : SSME Processing Model 
SSME PROCESSING MODEL 


When developing the new SSME Processing Model a major objective that needed to be 
met was its evolution into a generic Engine Processing Model that could easily be modified to 
represent other engines. This meant building into the SSME Processing Model features that 
would not specifically apply to SSME processing flow, but rather would be flexible enough to 
handle different types of processing flow. In this way, a number of trade studies could be 
performed by changing the processing flow and exploring the design space. To accomplish this 
objective a number of capabilities needed to be added to the model signifying a major departure 
from how the original model was setup. 

INDIVIDUAL ENIGNES 


A major difference between the original and new SSME Processing Models is how the 
engines are dealt with. The original model treated the engines as a cluster, if one engine was 
removed all the engines were removed. This method of modeling worked for the SSME model 




capabilities were added to the model representing a major departure from how the original model 
was setup. 

Individual Eniqnes : A major difference between the original and new SSME Processing 
Models is how the engines are dealt with. The original model treated the engines as a cluster. If 
one engine was removed, then all the engines were removed. This method of modeling worked 
for the SSME model, but is extremely limiting to the design space. Many of the engines and 
vehicles currently in the conceptual design phase call for engine maintenance to be performed on 
the vehicle. The engines are removed per a maintenance schedule or as necessitated by 
unplanned maintenance. With unplanned maintenance it may be necessary to remove only one 
engine and not the cluster. In order to remove a single engine, it became necessary for the 
model to deal with the engines individually. 

This methodology opens up the design space in which trade studies can be performed 
using this model. It is now possible to introduce scheduled maintenance that is tied to the 
number of flights of individual engines. For a conceptual vehicle with four engines, the model 
can handle the most extreme case in which one engine is removed and sent to the engine shop 
for maintenance, another engine is removed for depot maintenance, a third engine is removed 
and retired, and the last engine is left onboard the vehicle for regular maintenance. 

Excel Database : One of the major objectives for the new SSME Processing Model was to 
create a generic model that could easily be modified to represent other engines. Altering the 
mode! to treat the engines individually was the first step. The second step was to remove the 
engine specific data from the model leaving a generic core. To accomplish this objective, an 
Excel database was developed to hold all the engine data. A portion of the SSME Processing 
Model Excel database is shown in Figure 2. 

Built into Extend is the ability to link a model to an Excel file. At the beginning of the 
simulation, Extend reads all the data from an Excel file into a Global Data Array that is accessed 
by the model throughout the simulation. Dealing with engine data in this way has many 
advantages. A major advantage is centrally located user input data. When changes were made 
to maintenance tasks in the original SSME model, the user had to locate the specific task and 
make the required changes. If a large number of changes were needed, it would be time 
intensive to locate each maintenance task and make the changes. Using the Excel database, all 
the maintenance information is centrally located making it easy to input significant changes to the 
data without ever touching the model. 

The Excel database, as shown in Figure 2, is broken down into several sections. The 
first section deals with identifying the maintenance task. The first column shows the Task ID 
Number. It is through this number that the model knows which maintenance task is being 
performed. The next column in the database is a list of all the maintenance tasks performed. 

The next section deals with the distribution associated with each task. For the SSME Processing 
Model it is assumed that a lognormal distribution is applied with a mean and standard deviation 
provide by the user. The mean and standard deviation are represented by Parameterl and 
Parameter, respectively. Parameters is reserved for instances where the user chooses to use a 
distribution that requires three parameters. The next section of the database deals with 
Technical, Quality Control, Safety, and Engineering labor requirements and categories. These 
categories represent the number of personnel required to perform each task. The final section of 
the database deals with the frequency at which specific events occur. The first of these columns 
dictates task frequency. A (1 ) indicates that a task is performed every flight, a (2) indicates the 
task is performed once every two flights. The next three columns deal with how often an engine 
is removed and sent to the engine shop, how often an engine is sent for depot maintenance, and 
the life of an engine. 
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Frequencies : Allowing the SSME Processing Model to deal with the engines individually 
enables the model to handle maintenance schedules. Using the Excel database the user can 
change any of the frequencies to develop a maintenance schedule that is applied to all engines. 
The user can then perform trade studies using the frequencies to produce a desired turnaround 
time. The frequencies developed by performing trade studies become requirements for designers 
. The component’s development could work toward developing a component reliability that 
generates the required frequency and predetermined turnaround time. 

Unplanned Maintenance : A major advantage of modeling engines individually and 
developing a maintenance schedule is the ability to introduce unplanned maintenance. Within the 
new SSME Processing Model there is a block that deals with unplanned maintenance. The 
unplanned maintenance represents the probability of detecting something during post-flight 
maintenance checks that requires an engines removal, regardless of the engine’s maintenance 
schedule. This probability is tied to the number of flights the engines have made. The higher the 
number of flights, the greater the probability that something will occur requiring the engine’s 
removal. With this capability in the model, it is possible to have an engine cluster that contains 
engines that are at different places in their maintenance schedules, creating a realistic processing 
flow. This variability is another component to the trade space that effects turnaround time. 

Serial and Parallel Maintenance : Another capability of the SSME Processing Model is the 
ability to simulate maintenance task as either serial or parallel processes. By changing the 
succession in which tasks are performed, the user can perform a number of trades to determine 
the effect on turnaround time, if there is a significant benefit to performing a series of task in 
parallel it could have an effect on the design. The design would need to allow room for the 
required personnel to complete the tasks simultaneously. 

Labor Resources : Tied closely to the issue of serial and parallel maintenance are the 
effects of labor resources and the constraints they put on the simulation. As tasks are changed 
from serial to parallel, or parallel to serial, the minimum number of resources required change. If 
a number of tasks are being performed in parallel because they decrease the overall turnaround 
time the results should be weighted against the cost of having a larger work force. Does the 
saving in turnaround time justify the cost of the additional personnel? With any trade study the 
minimum number of resources should be examined to determine if the turnaround time saving 
offsets the increase in cost. 

Work Shifts : In addition to determining the number of personnel necessary to perform the 
required tasks, the number of shifts worked has an impact on turnaround time and costs. For the 
SSME Processing Model, it is assumed that there are two eight hours shifts per day, five days a 
week, and 52 weeks a year. When performing trade studies it may be beneficial to simulate a 
single work shift for certain facilities, such as the runway, and three shifts working in other areas 
like the OPF bays. Built into Extend is the ability to set up a work schedule that includes as much 
detail as the user deems necessary. A user could simulate work schedules that have down times 
due to holidays or lunch hours. 

Modeling Assumptions : Even with the bulk of the engine specific data centrally located in 
an Excel database, there are still a number of engine specific assumptions built into the model 
that can be changed for new engine concepts or trade studies. These assumptions are generally 
program level, such as the number of spare engines present in the simulation, the total number of 
engines in the program, and how many engines are on a vehicle. Also, the user can change the 
number of facilities being simulated. The model is setup in such a way that the user can easily 
change the number of OPF bays or number of launch pads to be simulated without making 
extensive changes to the model. 

SSME Maintenance Block : At the heart of the SSME Processing Model is the Engine(s) 
Maintenance Task Block. The Engine(s) Maintenance Task Block, as shown in Figure 4, has 
been customized for the maintenance performed in the OPF and is comprised of several 
components; the Frequency Decision Block, Calculation Block, OPF Bay Assignment I Block, Pull 
Resource Block, Perform Task (OPF) Block, Resource Release Block, OPF Bay Assignment II 
Block, Maintenance Loop Decision Block, and Maintenance Data Block. The Maintenance Data 


Block located across the bottom of the Engine(s) Maintenance Task Block is the only part of the 
block requiring user inputs. The Start and End Task ID Numbers are the only engine specific data 
captured by the Engine(s) Maintenance Task Block. The ID Numbers translate directly to the ID 
Numbers in the Excel database. For the example shown in Figure 4, Tasks 40 through 53 are 
performed in serial by this specific block. The user also specifies which type of distribution will be 
used to calculate the task duration and the resource pools to be used. There are four resource 
pools used, Technical, Quality Control, Safety, and Engineering, but there are individual resource 
pools used for the runway, OPF, VAB/Pad, engine shop and depot maintenance, therefore, the 
resource pool being used needs to be specified. 

When an engine cluster enters the Engine(s) Maintenance Task block, the first 
component in the maintenance flow is the Frequency Decision block responsible for determining 
whether the maintenance task is performed based upon the task frequency and the number of 
engine flights. If maintenance is performed, the engine proceeds to the Calculation Block shown 
in Figure 5. The Calculation Block is where task duration and man-hours are calculated based 
upon data in the Excel database. The areas of the Calculation Block titled Task Decision Maker, 
Labor Data Retrieval, and Parameter Retrieval contain a number of Global Array Blocks as 
shown in Figure 6. These are responsible for retrieving specific data from the database based 
upon inputs that specify the row and column in the database where the required data is located. 
The column value is a constant and does not change while the row value is equal to the Task ID 
Number of the task being performed. Based upon the series of tasks specified by the user, the 
mode! wi!! change the Globa! Array Block row value so the appropriate maintenance task data is 
retrieved from the database. Data retrieved from the database in the Calculation Block is used by 
the Maintenance Calculation Block, shown in Figure 7, to calculate task duration and technical, 
quality control, safety, and engineering man-hours required. 

The next step in the Engine(s) Maintenance Task block is to separate the engines into 
their respective OPF bays. Since the SSME Processing Model treats the engines individually, 
and the processing flow for each OPF bay over lays each other, it is important to keep track of 
which engine belongs in which bay. It is important to know the location of each engine because 
in certain facilities, such as the OPF, one engine in a cluster is worked on at a time, and it is 
important to make sure the maintenance task has been performed for each engine in the cluster 
before beginning the next maintenance task. The accounting of the engines is performed by the 
OPF Bay Assignment I and OPF Bay Assignment II blocks. 

Upon exiting the OPF Bay Assignment I block, engines enter the Pull Resource block. 
Here, the required personnel are pulled from their respective resource pools so that the engine 
and personnel can proceed to the Perform Task block. The Perform Task block holds the 
engines and resources for a period equivalent to the task duration calculated by the Calculation 
Block. Next the engines enter the Resource Release block where the personnel are released 
back to the resource pools to be used in the next maintenance task. The last component of the 
Engine(s) Maintenance Task block is the Maintenance Loop Decision block which is responsible 
for making sure all maintenance tasks specified by the user have been performed. If not, the 
engines are sent back to the beginning of the block for performance of the next maintenance 
task until all specified tasks have all been performed. 







Figure 5: Calculation Block 


Figure 6: Global Block 
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Figure 7: Maintenance Calculation Block 


SSME TRADE STUDY 


Using the SSME Processing Model it is possible to perform a series of trade studies to 
determine ways of decreasing the turnaround time of the SSMEs. The following is an example 
trade study showing how turnaround time for SSMEs can be decreased simply by changing a few 
assumptions. In this trade study, four case studies were performed in addition to the nominal. 

For all the case studies, the general assumptions were that the simulation would model the 
Shuttle maintenance flow simulating a single Orbiter and three SSMEs. Additional assumptions 
are two eight hour shifts per day, five work days per week, and fifty-two weeks per year. 

Nominal Case: The SSME Processing Model was run without any changes to the model. 
These results would resemble the actually turnaround time of the SSMEs from landing to launch. 
For the nominal case the turnaround time is 1504 work hours or 4.7 months. 






Case Study 1 : The first case study uses the nominal case with the added assumption of 
three spare engines being configured so that when one cluster of engines is removed another 
cluster is ready to be installed. The result for this study is a turnaround time of 989 work hours or 
3.1 months. 

Case Study 2: The second case study uses the nominal case, but it is assumed that the 
engines can remain on the vehicle while maintenance is performed. Study 2 also assumes 
personnel working the engines would have unlimited access to the aft compartment of the Orbiter 
and would not be impeded by crews working on the Orbiter. While the engine crews would have 
unlimited access to the engines, the constraints of the vehicle and space available require that 
only one engine worked on at a time. The turnaround time for this case is 2010 work hours or 6.3 
months. 


Case Study 3: The third case study builds off Case Study 1 with the added assumption 
that the SSMEs are installed on a new vehicle that has space available to allow work crews to 
work on all three engines simultaneously. This case study is setup to show advantages, if any, 
gained by having dedicated crews working on each engine. The result for this study is a 
turnaround time of 390 hours or 1 .3 months. 

Case Study 4: The final case study takes Case Study 3 a step further and makes the 
assumption that all three engines could be removed as a cluster instead of individually. The 
result of this study is a turnaround time of 343 hours or 1 .1 months. 

Summary: The resuits of these five cases can be seen in Table 1 and in Figure 8. An 
important part of any trade study is examining the affect on turnaround time. The trade studies 
performed here focus on only a few contributing factors. For Case Study 1 it was assumed that 
there were three spare engines in the flow such that when an engine cluster was removed 
another was waiting to be installed. This saves over 500 work hours and allows the vehicle to get 
an extra flight in each year. What this example doesn’t take into account is the additional cost to 
the program of having an additional three engines just for an extra flight a year. If the Shuttle 
program operated this way, a fleet of three Orbiters, an additional nine SSMEs, would need to be 
purchased. What needs to be examined are the cost benefits of purchasing three additional 
engines versus having three flights a year instead of two. 

Not only is it important to take into consideration all aspects of turnaround time, such as 
cost or personnel, but to be able to examine why the trade studies produce the results. This can 
clearly be seen with Case Study 2. It is normally argued that on vehicle maintenance would have 
a large impact on decreasing turnaround time. Case Study 2 shows that the turnaround time 
increases by over 500 work hours. In this example it was assumed that the engines would 
remain on the vehicle and that each engine would be worked on one at a time. While this 
eliminates the time required to remove and replace the engines, it increases required engine 
turnaround time, this results because, the SSME Processing Facility, the engines have their own 
bay and can be worked on simultaneously, while in the OPF, they have to be worked serially 
because of space constraints in the aft compartment of the Orbiter. 

Other constraints that are at a constant tug with turnaround time are number of personnel 
and personnel cost. When examining case study three and four it is assumed that the “new” 
Orbiter has the room in the aft compartment to work on the engines simultaneously, and case 
study four assumes that the engines can be removed and replaced as a cluster. In order to work 
on the engines simultaneously, it would require that two additional crews be hired such that each 
engine would have a dedicated crew, and for Case Study 4 and new engine carrier would have to 
be purchased. It may be that for Case Study 3 the additional personnel required, and the cost 
associated, are out-weighted by the fact that the vehicle is achieving nine flights per year instead 
of three. For Case Study 4 it could turn out to be that the cost associated with a new engine 
handler, which can remove all three engines at the same time, out weights the benefits of gaining 
an extra flight a year. Both of these case studies require an in depth examination of all the 
possible contributing factors. 


Tablel : SSME Trade Study Results 
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Figure 8: Turnaround Time (Landing to Launch) 

One of the important aspects of a trade study, as shown in this example, is to 
demonstrate how changing a few assumptions can dramatically alter turnaround time and have 
an effect on the design of the vehicle. However, as shown with the SSME example, there are a 
number of factors such as cost, personnel requirements, and others that would need to be 
examined to fully explore the design space. When developing a model for a reusable engine in 
the conceptual design phase it is important to fully explore the design space to develop and 
optimize the turnaround time while minimizing cost and personnel. 

SUMMARY AND CONCLUSIONS 

The SSME Processing Model allows users to simulate the maintenance required by the 
SSMEs and then perform a number of trades to explore the design space in hopes of determining 
optimum solutions for decreasing turnaround time and cost. This same process can be 























performed on conceptual engines and the results given to designer engineers. By performing 
trade studies it could be determined whether it would be beneficial to have a particular part 
removed once every tenth flight due to the amount of time required remove and replace the 
component, or once every fifth flight. This information could be turned into a reliability used by 
designers to meet the objective of a pre-determined desired turnaround time. If it is not possible 
to reach such a reliability, the model could be amended and the trades run again with the new 
inputs. As the design matures, the data in the model can be updated allowing the model to stay a 
step ahead of the design, performing trade studies and providing feed back to the designers 
regarding operational concepts that need to be met. 

FUTURE WORK 

Currently the SSME Processing Model only simulates planned maintenance performed 
on the SSMEs. The next step in the development of the SSME Processing Model is the addition 
of unplanned maintenance. In the research completed in 1998 by Mr. Christenson and Mr. 

Komar data was collected on unplanned maintenance which was included in the original model. 

In the process of developing a new SSME Processing Model, it was convenient to remove the 
unplanned maintenance in order to validate the model. Now that the model has been validated, 
the unplanned maintenance can be added back into the model. 

Another aspect of the SSME Processing Model that still requires work is upgrading the 
model from Extend Version 5 to Extend 6 'with Industry. Industry is an add -on package 
developed by Simulation Dynamics that contains several capabilities that could be beneficial to 
the SSME Processing Model. One feature of Industry is a database capability that would 
eliminate the need for the Excel database and allow all the engine specific data to reside in a 
database located within Extend. This capability allows for changes to be made to the database 
while the simulation is running. A user could be running a simulation that uses two shifts per day 
and during the simulation change the number of shifts to three and see instantly the effect on 
efficiency instead of having to start another simulation. Another feature developed by Simulation 
Dynamics is a Design of Experiments (DoE) block which allows the user to set up a DoE and then 
begin the simulation which would perform each case in the DoE. After the first case is run the 
model makes the corresponding changes to the data/model and begins the simulation with a new 
set of assumptions. Such a feature would be extremely useful in determining optimum operating 
conditions. 
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